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Abstract 

Mission  planning  has  come  a  long  way  from  the  days  of  the  Wright  brothers  first 
flight  in  1903.  Today,  mission  planning  has  grown  into  an  activity  as  complex  as  the 
machines  that  carry  out  the  missions.  No  longer  a  luxury,  automated  mission  planning 
systems  are  vital  to  the  success  of  current  and  future  air  operations. 

The  history  of  automated  mission  planning  development  has  been  a  chaotic 
combination  of  official  systems  and  grassroots  stovepipes.  The  Air  Force  has  always 
leaned  towards  Unix  based  mission  planning  systems,  but  recent  growth  in  the 
microprocessor  industry  has  made  personal  computers  a  viable  option.  The  Air  Force’s 
continued  emphasis  on  Unix  based  mission  planning  systems  designed  to  do 
everything  for  everyone  has  created  a  bottleneck  which  may  become  a  critical 
failure  point  when  examined  in  light  of  increasing  mission  planning  requirements. 
This  paper  relies  on  up  to  date  information  obtained  through  interviews  and  recent 
publications  to  analyze  this  bottleneck  from  the  perspective  of  F-16  mission  planning. 

As  F-16  mission  planning  requirements  grew  through  the  early  1980’s,  early  mission 
planning  systems  progressed  along  two  paths.  The  larger  effort  was  in  the  large  Unix 
based  systems,  which  were  generally  better  funded  and  large  scoped  projects.  The 
second  path  was  personal  computer  (PC)  based  systems,  and  while  smaller  in  every  sense 
has  always  been  the  preferred  path  by  the  users. 
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Currently,  two  members  of  the  Air  Force  Mission  Support  System  (AFMSS)  family 
dominate  mission  planning:  the  Unix  based  Mission  Planning  System  (MPS)  and  the  PC 
based  Portable  Flight  Planning  Software  (PFPS).  The  size,  cost,  usability,  and  portability 
of  the  MPS  systems  have  created  a  bottleneck  that  threatens  the  future  of  mission 
planning  unless  a  new  direction  is  taken.  This  new  direction  must  feature  heavier  use  of 
PC  systems,  with  emphasis  on  integrated  products  as  opposed  to  one  master  mission 
planner  that  attempts  to  fulfill  everyone’s  needs. 

Several  future  projects  hold  promise  to  break  this  bottleneck.  The  Joint  Mission 
Planning  Segment  (IMPS)  is  a  cooperative  effort  between  the  Air  Force  and  the  Navy 
which  will  provide  a  scaleable,  tailorable  solution  for  mission  planning.  CyberWarrior 
Insights  is  a  PC  based  add-on  program  for  PFPS  designed  to  provide  a  virtual  scheduling 
and  training  shop  which  will  integrate  and  automate  these  functions  with  mission 
planning.  Similarly,  the  Flight  Information  Enhancement  (FIE)  attempts  to  develop  a 
PEPS  add-on  that  provides  virtual  base  operations  functions.  All  of  these  take  mission 
planning  in  the  right  direction — customizable  PC  based  systems. 

If  the  Air  Eorce  is  going  to  meet  today’s  demands  for  activities  such  as  precision 
strike  and  multinational  operations  as  well  as  meet  the  challenges  of  the  dynamic  changes 
outlined  in  Joint  Vision  2010 — then  new  directions  must  be  explored  in  automated 
mission  planning.  Continued  reliance  on  inappropriate  Unix  systems  must  be  abandoned, 
and  the  bottleneck  broken  in  favor  of  PC  based  solutions. 
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Chapter  1 


Introduction 

Since  the  Wright  brothers  first  flew  in  1903,  aviators  have  had  to  engage  in  one  form 
or  another  of  mission  planning.  For  Orville  and  Wilbur,  it  may  have  been  as  simple  as 
tossing  a  few  blades  of  grass  in  the  air  to  check  the  wind.  Today’s  aviators  have  a  far 
more  daunting  task  when  it  comes  to  mission  planning. 

Mission  planning  has  grown  into  an  activity  as  complex  as  the  machines  of  today’s 
skies.  Planning  is  much  more  involved  than  the  days  of  old — the  new  age  aviator  must 
factor  in  communications,  weaponry,  routing,  computer  programming,  and  a  myriad  of 
other  preflight  factors.  In  order  to  help  the  aviator  deal  with  these  complexities, 
automated  mission  planning  systems  were  developed.  These  systems  rapidly  grew  from 
a  luxury  to  a  necessity  as  the  demands  for  premission  data  processing  and  transfer 
increased. 


Breaking  the  Mission  Planning  Bottleneck 

Early  attempts  at  automated  mission  planning  solutions  resulted  in  multiple 
stovepipe  systems,  developed  to  meet  the  needs  of  various  individual  user  communities. 
In  the  early  1990’s,  Air  Force  development  was  focused  on  improving  and  uniting 
automated  mission  planning  technology.  The  Air  Force  Mission  Support  System 
(AFMSS)  was  designed  to  replace  the  various  stovepipe  systems  and  provide  better 
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integration  of  data.  At  the  time  AFMSS  was  developed,  microproeessors  found  in 
personal  eomputers  were  inadequate  for  the  demands  of  mission  planning.  AFMSS 
systems  were  therefore  hosted  on  Unix  based  systems  out  of  necessity.  Since  that  time 
the  rapid  improvements  in  the  desktop  computer  industry  have  made  personal  computers 
a  viable  and  logical  alternative  to  larger  proprietary  systems  which  try  to  put  everything 
in  one  box.  The  Air  Force’s  continued  emphasis  on  Unix  based  mission  planning 
systems  designed  to  do  everything  for  everyone  has  created  a  bottleneck  which  may 
become  a  critical  failure  point  when  examined  in  light  of  increasing  mission 
planning  requirements. 


Methodology 

This  paper  will  analyze  this  bottleneck  from  the  perspective  of  mission  planning  for 
the  F-16.  As  a  multirole  fighter,  the  F-16  has  been  at  the  forefront  of  mission  planning 
since  the  early  1980’ s.  It  has  experienced  the  full  spectrum  of  mission  planning  systems, 
from  early  stovepipes  to  the  large  Unix  based  systems.  Examining  the  impact  of  Air 
Force  mission  planning  development  on  the  F-16  community  allows  us  to  draw  some 
conclusions,  many  of  which  apply  to  Air  Force  mission  planning  in  a  larger  sense. 

As  with  most  areas  in  the  computer  field,  things  change  at  such  a  rapid  pace  that 
published  sources  are  oftentimes  obsolete  by  the  time  they  see  print.  Test  reports  from 
mission  planning  systems  provide  data  on  capability  and  suitability,  however  this  paper  is 
based  primarily  on  interviews  with  people  across  the  full  spectrum  of  mission  planning 
development.  They  provide  perspectives,  which  are  in  tune  with  the  rapidly  changing 
environment  of  automated  mission  planning  development. 
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Before  beginning  a  discussion  of  a  new  paradigm  for  mission  planning,  it  is 
important  to  understand  how  the  Air  Force  got  to  the  current  point.  This  paper  will  begin 
by  examining  the  rise  of  mission  planning  requirements  and  systems.  Following  that,  an 
examination  of  current  systems  capabilities  and  limitations  will  be  discussed.  Finally, 
this  paper  will  look  forward  and  propose  a  new  direction  for  Air  Force  mission  planning. 
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Chapter  2 


The  Past  -  Birth  of  Automated  Mission  Planning 

The  Growth  of  F-16  Mission  Planning  Requirements 

Automated  mission  planning  for  the  F-16,  as  with  most  aircraft,  started  out  as  a 
luxury.  Pilots  would  spend  hours  in  the  planning  room  with  paper,  pencil,  and  charts. 
The  results  of  these  efforts  were  recorded  on  various  slips  of  paper  such  as  lineup  cards 
and  data  sheets,  and  hand  entered  into  the  aircraft  for  flight.  As  the  F-16  mission  grew 
more  complex,  the  amount  of  data  required  to  be  transferred  to  the  aircraft  exceeded  the 
pilot’s  ability  to  enter  it  by  hand.  Thus  was  bom  the  data  transfer  cartridge  (DTC)  for  the 
F-16C. 

DTC’s  provided  the  pilot  a  quick  method  for  loading  preflight  data  into  the  aircraft, 
and  the  history  of  DTC  memory  capacity  increases  provides  a  quick  snapshot  of  the 
incredible  growth  of  F-16  mission  planning  needs 

•  Pre-1980:  data  entered  by  hand 

•  1981:  8K  DTC’s 

•  1987:  64K  DTC’s 

•  1990:  128K  DTC’s 

•  1996:  32  and  72  megabyte  DTC’s 

Initially,  the  capacity  of  the  DTC  was  small  enough  that  the  pilot  could  easily  enter 
the  critical  data  into  the  aircraft  by  hand  if  necessary.  Soon  the  amount  of  data  being 
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loaded  into  the  aircraft  exceeded  the  capability  of  the  pilot  to  type  it  in  manually.  At  this 
point,  mission  planning  systems  moved  from  being  a  luxury  to  a  necessity. 


Early  Mission  Planning  System  Development 


The  explosive  growth  of  F-16  mission  planning  data  requirements  led  to  the  need  for 
systems  capable  of  loading  these  DTC’s.  The  early  history  of  automated  mission 
planning  (depicted  in  Figures  1  and  2)  is  a  tale  of  two  paths.  The  first  taken  was  that  of 
the  officially  sponsored  Air  Force  systems.  This  began  in  1980  with  the  Computer-Aided 
Mission  Planning  System  (CAMPS).  This  was  soon  followed  by  the  Unix  based  CS2 
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Figure  1.  Mission  Planning  History — Part  1? 

system  in  1981,  which  matured  into  the  Mission  Support  System  (MSS  I)  in  1983.  All 
of  these  systems  were  large  Unix  based  computers  which  provided  the  capability  to  do 
mission  planning  using  a  graphical  interface  with  charts,  and  load  DTC’s  to  transfer  data 
to  the  aircraft.  The  MSS  systems  went  through  several  upgrades,  finally  being  replaced 
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by  the  newer  Air  Force  Mission  Support  System  (AFMSS)  in  1992.  The  AFMSS  system 


was  another  Unix  based  computer  system,  even  larger  than  its  predecessor,  the  MSS  IL 
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Figure  2.  Mission  Planning  History — Part  2/ 

The  second  path  mission  planning  took  was  the  smaller  effort  of  personal  computer 


(PC)  based  planning.  These  efforts  were  grass  roots  based  development,  literally 


beginning  in  someone’s  garage  with  no  funding  at  all.  Computer  savvy  pilots,  frustrated 


with  the  size  and  complexity  of  the  official  Air  Force  systems,  set  out  to  create  something 


small,  fast,  and  friendly.  In  1981  aircrews  wrote  DTC  Loader  Reader  (DTCLR).  This 


was  a  very  rudimentary  program  allowing  pilots  to  load  and  read  DTC’s  quickly  without 
having  to  battle  the  complexities  of  the  large  Unix  systems.^  In  1984,  a  small  group  of 


pilots  at  Myrtle  Beach  AFB  developed  Flight  Planner  (FPLAN)  to  aid  with  A- 10 
planning.^  This  DOS  based  program  provided  fast  efficient  text  based  flight  planning 


without  all  the  bells,  whistles,  and  complexities  of  the  large  systems.  The  popularity  of 
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FPLAN  with  the  aircrews  caused  the  Air  Force  to  adopt  it  as  a  minimally  funded  effort  in 
the  late  1980’ s. 

The  two  development  paths  have  crossed  twice.  In  1989,  the  popularity  of  the  PC 
based  FPLAN  products  prompted  Tactical  Air  Command  (TAC)  to  direct  further  efforts 
at  mission  planning  to  have  a  “common  FPLAN  like  look  and  feel.”  This  resulted  in  two 
changes.  First,  new  MSS  II  updates  became  more  user  friendly  as  they  mimicked  the 
more  commonly  used  FPLAN  interface.  Second,  the  unified  direction  from  TAC  allowed 
parallel  development  on  both  the  Unix  and  PC  platforms  for  the  first  time.  While  the  two 
systems  were  still  separate  programs,  they  were  now  moving  closer  together.  Beginning 
in  1990  with  Combat  Weapons  Delivery  Software  (CWDS),  this  parallel  effort  resulted  in 
programs  being  written  for  Unix  and  PC  platforms  at  the  same  time.  This  allowed  users 
to  go  to  either  platform  and  see  essentially  the  same  interface,  as  well  as  share  some  data 
files  between  the  two  systems. 

This  direction  from  TAC  also  resulted  in  a  bona  fide  PC  development  effort.  While 
FPLAN  continued  on  its  shoestring  budget,  a  new  PC  effort  began.  This  new  effort 
produced  products,  which  paralleled  the  large  Unix  system  functions:  Combat  Flight 
Planning  Software  (CFPS),  Falcon  View,  CWDS,  and  DTC  load  software.  Originally 
developed  as  DOS  based  programs,  these  programs  moved  to  the  Windows  environment 
in  1996.  Collectively  referred  to  as  Portable  Flight  Planning  Software  (PFPS),  they 
provided  more  capability  than  FPLAN,  while  retaining  the  overall  speed  and  simplicity 
that  made  FPLAN  popular. 

The  direction  to  develop  a  common  interface  worked  well  for  the  MSS  II  system. 
When  the  AFMSS  system  debuted  in  1992,  however,  the  automated  mission  planning 
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systems  started  diverging  again.  While  the  MSS  II  program  was  run  from  TAG  (and  later 
Air  Combat  Command  [ACC]),  the  AFMSS  program  was  run  by  Electronic  Systems 
Command  (ESC).  This  change  in  management  and  vision  led  the  AEMSS  in  a  different 
direction  than  the  MSS  II  program.  The  goals  for  AEMSS  were  much  more  aggressive: 
“the  primary  goal  of  AEMSS  is  to  provide  a  unit-level  mission  planning  capability  for 
airlift,  bomber,  fighter,  special  operations,  and  tanker  aircraft.”  Additionally,  far  greater 
emphasis  on  the  AEMSS  as  a  command,  control,  communications,  computer,  and 

o 

intelligence  (C4I)  asset  added  further  complexity  to  the  program.  The  “one  box  fits  all” 
concept  led  the  AEMSS  to  diverge  significantly  from  the  PC  products  once  again. 

In  1996  the  mission  planning  development  paths  crossed  for  a  second  time.  Prior  to 
this  the  Unix  and  PC  efforts  were  separate  projects.  After  1996,  the  two  systems  were 
joined  under  one  umbrella  -  the  AEMSS  family  of  mission  planning  products.  The  large 
Unix  systems  were  now  referred  to  as  Mission  Planning  Systems  (MPS),  and  the  PC 
versions  as  PEPS  products.  After  the  initial  divergence  of  the  AEMSS  and  PC  products, 
they  were  brought  back  into  the  same  program  and  a  link  reestablished  between  the  two 
systems.  While  AEMSS  had  grown  too  large  to  adopt  the  PC  look  and  feel  in  most  areas, 
efforts  were  made  to  increase  the  interoperability  of  the  two  systems  through  file  sharing 
and  data  exchange  whenever  possible. 

Analysis  of  Mission  Planning  History 

The  two  paths  taken  in  mission  planning  system  development  result  in  some  general 
observations.  The  path  of  the  Unix  based  systems  is  usually  a  better  funded  and  larger 
scoped  effort.  It  is  pursued  using  classical  acquisition  methods,  and  tends  to  respond 
rather  slowly  to  user  requests  for  change.  The  second  path,  PC  based  systems,  has 
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traditionally  been  a  much  smaller  effort — both  in  funding  and  scope. ^  The  PC  systems 
tend  to  be  developed  in  incremental  steps,  and  respond  quickly  to  user  feedback. 

This  second  path  has  historically  been  much  more  popular  with  aircrews  for  several 
reasons.  First  of  all,  the  PC  systems  have  always  targeted  the  “80%  solution.”  Instead  of 
trying  to  implement  every  function  imaginable,  the  developers  of  PC  systems 
concentrated  on  doing  the  basic  functions  in  a  quick  and  efficient  manner.  This  fit  with 
the  inherent  limitations  of  PC  systems  in  terms  of  storage,  display,  and  computational 
power — and  resulted  in  a  system,  which  was  easy  to  understand  and  use. 

Second,  the  PC  systems  were  in  a  better  position  for  acceptance  due  to  much  greater 
user  familiarity.  Most  users  were  familiar  with  PC  operations,  and  could  quickly  adapt 
their  knowledge  to  using  the  PC  systems.  The  Unix  based  systems,  on  the  other  hand, 
were  a  foreign  environment.  Standard  keystrokes  which  pilots  used  on  their  home  PCs 
would  bring  strange  results  or  not  work  at  all  on  the  Unix  systems.  The  introduction  of 
the  AFMSS  system  exacerbated  the  problem.  After  years  of  effort  driving  the  MSS  II 
and  the  PC  systems  to  use  a  common  interface,  AFMSS  came  along  and  changed  nearly 
every  aspect  of  mission  planning  on  the  large  Unix  systems.  While  the  AFMSS  was  a  far 
more  capable  hardware  suite  than  the  MSS  II,  the  methodology  used  to  mission  plan  was 
so  different  from  the  established  systems  that  it  was  very  difficult  for  users  to  operate. 

The  result  of  these  observations  is  that  there  is  an  inherent  advantage  to  developing 
mission  planning  on  a  PC  platform.  With  ops  tempo  an  issue  everywhere,  time  for 
training  is  at  a  premium.  Systems  developed  with  user’s  inherent  knowledge  of  PC 
operations  as  a  going  in  position  are  going  to  be  useable  much  faster,  and  thus  accepted 
quicker  and  at  a  lower  cost.  Leveraging  the  user’s  established  familiarity  with  PC 
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operations  minimizes  any  training  requirements.  The  hardware  cost  of  the  systems 


themselves  is  an  issue,  which  will  be  addressed  in  the  next  section. 
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Chapter  3 


The  Present — At  the  Crossroads 

Current  Automated  Mission  Planning  Solutions 

Automated  mission  planning  for  the  F-16  currently  comes  in  two  flavors:  MPS  and 
PFPS.  The  MPS  system  is  the  large  Unix  based  system  that  was  last  updated  in  1997.  A 
typical  F-16  squadron  would  have  2  MPS  II  stations  with  2  planning  seats  each  and  two 
Portable  Mission  Planning  Systems  (PMPS).  The  current  PFPS  mission  planning  suite 
was  updated  for  the  Windows  95  operating  system  in  1997.  In  order  to  equip  a  typical  F- 
16  squadron  with  the  same  number  of  planning  stations  would  take  6  PC  computers  and  6 
Ogden  Data  Device  3  (ODD-3)  cartridge  load  units. 

There  are  differences  between  the  systems  that  should  be  identified.  The  MPS 
stations  are  designed  to  do  far  more  than  the  PFPS  suite  for  PC’s.  According  to  MPS 
documentation,  MPS  is  “an  integrated,  networkable,  multiple  user,  deployable  mission 
planner  designed  to  receive  data  from  various  sources  to  plan  a  mission  and  provide  both 
printed  and  electronic  documentation.”^  The  scope  of  operations  for  MPS  is  actually  far 
more  than  just  mission  planning  for  the  individual  aircrew  member. 

The  PFPS  suite  is  a  set  of  tools  designed  specifically  for  the  individual  planner. 
While  they  do  integrate  with  each  other  and  will  take  data  from  other  sources,  PFPS  is 
not  designed  nor  equipped  to  attempt  the  full  spectrum  of  integrated  planning  activities 
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that  an  MPS  station  is  designed  to  perform.  With  this  basic  differentiation  in  mind,  the 
problems  of  the  status  quo  can  be  examined. 

Problems  With  Current  Situation 

There  are  several  problems  with  automated  mission  planning  as  it  exists  today.  They  can 
be  summed  up  in  four  areas:  size,  cost,  usability,  and  portability.  The  first  of  these  is  the 
physical  size  of  the  systems  and  the  associated  demands  on  a  squadron.  The  MPS 
systems  are  very  large,  far  larger  than  their  predecessor  MSS  II  systems. 


Figure  3.  MPS  I  Two  Station  Layout^ 

Depending  on  the  specific  configuration  and  layout,  an  MPS  I  system  takes 
approximately  75  square  feet  to  set  up  each  station.  Figure  3  shows  the  layout  of  a 
typical  two  seat  station.  Due  to  the  nature  of  some  mission  planning  data  the  MPS 
stations  must  be  set  up  in  a  secure  location.  The  demands  of  these  systems  for  floor 
space  can  cause  problems  with  available  secure  locations,  which  is  at  a  premium  in  most 
F-16  squadrons.  This  problem  is  more  pronounced  in  a  deployed  situation 
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In  contrast,  the  PFPS  systems  can  be  as  large  or  as  small  as  the  user  desires.  The 
CD-ROM  based  software  can  be  loaded  on  any  system  running  Windows  95 — from  a 
large  desktop  system  to  a  portable  notebook.  Figure  4  depicts  a  laptop  computer  based 
PFPS  system  ready  to  flight  plan  and  load  cartridges  for  an  F-16.  The  ODD-3  device 
used  to  load  cartridges  is  roughly  the  size  of  half  a  loaf  of  bread.  In  contrast  to  the  MPS 
systems  that  require  specific  space  intensive  hardware,  these  systems  are  scaleable.  The 
requirements  for  floor  space  are  a  far  cry  from  those  of  the  MPS  systems. 


Figure  4.  Typical  PFPS  System  for  F-16  mission  planning/ 

Cost  disparity  is  the  second  problem  with  current  systems.  The  cost  to  equip  a 
squadron  with  MPS  systems  is  shown  in  Table  1: 
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Table  1.  MPS  Cost  per  F-16  Squadron 


Cost  per  Item 

Items  per  Squadron 

Cost  per  Squadron 

MPS  II 

$ 

170,000 

2 

$  340,000 

PMPS 

$ 

40,000 

2 

$  80,000 

TOTAL  COST: 

$  420,000 

Source:  Maj  Tom  Martin,  HQ  ACC/SMO-P,  Langley  AFB,  Virginia.  Interviewed  by 
author,  March  1998. 


Any  planning  capability  the  squadron  desires  above  and  beyond  the  6  stations  would 
raise  the  cost  significantly.  Users  have  no  option  other  than  purchase  the  expensive  Unix 
based  MPS  stations  to  expand  mission  planning  capability  to  support  operations.  For 
example,  a  unit  may  desire  to  have  additional  mission  planning  hardware  packed  and 
ready  for  rapid  strategic  mobility  as  envisioned  in  Joint  Vision  201 0^  Purchasing  one 
additional  MPS  II  station  and  two  PMPS  units  to  enhance  mobility  will  cost  the  squadron 
a  quarter  million  dollars — not  a  very  enticing  motivation  to  be  prepared  for  rapid 
reaction. 

The  cost  to  equip  a  unit  with  this  PC  hardware  is  shown  in  Table  2: 


Table  2.  PFPS  Cost  per  F-16  Squadron 


Cost  per  Item 

Items  per  Squadron 

_Cost  per 
Squadron 

Computer 

$ 

2,500 

6 

$  15,000 

ODD-3 

$ 

2,500 

6 

$  15,000 

TOTAL  COST: 

$  30,000 

Source:  Vance  Willsey,  Lockheed  Martin  Tactical  Aircraft  Systems,  Hill  AFB,  Utah, 
interviewed  by  author,  January  1998. 


Again,  this  provides  planning  capability  for  6  stations.  Additional  planning  stations  may 
or  may  not  require  any  more  outlay  of  funds  by  the  squadron.  Since  the  software  is 
written  for  any  Windows  95  platform  and  is  free  to  the  users,  it  can  be  loaded  on  any 
compatible  computer.  This  means  that  not  only  can  the  squadron  set  up  additional 
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planning  stations  in  the  squadron,  but  that  aircrews  can  also  plan  at  home  on  their 
personal  machines  if  desired — all  at  no  cost  to  the  squadron. 

The  third  area  of  difficulty  is  that  of  usability.  As  previously  mentioned,  the  large 
Unix  based  MPS  systems  operate  very  differently  than  the  PC  systems  which  most  users 
are  accustomed  to  using.  This  lack  of  familiarity  with  Unix  type  systems  causes 
significant  frustration  amongst  users,  and  substantially  increases  the  learning  curve  for 
efficiently  operating  the  system.  The  PC  systems  have  been  designed  with  one  central 
design  theme:  “make  it  work  like  Microsoft  Office.”^  Any  user  who  is  even  remotely 
familiar  with  Microsoft  Office  (Air  Force  standard  software)  can  most  likely  operate  the 
PFPS  software  “out  of  the  box.”  One  ACC  headquarters  officer  was  introduced  to  PFPS 
during  a  mission  planning  meeting  in  1997.  He  had  just  completed  a  two  week  course 
learning  how  to  use  the  MPS  system.  After  15  minutes  using  PFPS  installed  on  a  laptop 
he  commented  “I’ve  learned  more  in  10  minutes  on  my  own  with  this  software  than  I  did 
during  two  weeks  of  training  on  the  MPS.”^ 

The  final  problem  area  is  portability.  With  the  current  MPS  beddown  of  two  2-seat 
stations  and  two  PMPS  systems  per  squadron,  you  are  limited  in  how  many  locations  you 
can  plan.  If  a  squadron  is  deploying  to  a  forward  location  with  airlift,  they  have  the 
option  of  taking  an  MPS  II  that  will  take  a  full  pallet,  or  a  PMPS  stored  in  two  small 
suitcase  units.  If  they  do  not  have  airlift  support  (especially  likely  in  the  event  of  a  small 
deployment)  the  squadron  can  take  a  PMPS  in  an  aircraft  mounted  travel  pod.  This 
assumes  that  one  or  more  aircraft  will  have  a  travel  pod  with  enough  space  to  stow  the 
two  suitcases.  If  the  squadron  is  deploying  aircraft  without  airlift  or  travel  pod  space, 
then  neither  MPS  nor  PMPS  can  support  the  operation  unless  it  is  prepositioned  through 
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some  other  method.  The  PFPS  system  is  much  more  portable.  A  user  can  take  a 
notebook  computer  and  an  ODD-3  and  have  the  capability  to  plan,  load,  and  read  DTC’s 
at  any  location.  If  the  deployed  location  will  have  any  computers  available,  the  notebook 
computer  could  even  be  left  behind,  and  just  an  ODD-3  and  the  PFPS  software  carried 
and  set  up  at  the  new  location. 

Why  Current  Air  Force  Direction  Is  Inadequate 

The  Air  Force’s  major  mission  planning  effort  is  still  currently  the  Unix  based  MPS 
systems.  There  are  two  primary  factors  that  led  to  the  current  state  of  Air  Force  mission 
planning  systems:  technological  state  of  the  art  and  the  desire  to  create  the  ultimate 
planning  machine.  Examining  each  of  these  reveals  why  continued  emphasis  on  systems 
such  as  MPS  would  not  serve  the  warfighter’s  needs  in  the  future. 

Abandoning  The  Unix  Paradigm 

The  MPS  systems  were  initially  designed  in  early  1991  .  In  this  time  frame,  most 
PC  systems  were  running  386  microprocessors  and  DOS;  Windows  3.0  had  been  out  for 
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less  than  a  year  .  At  this  time  it  made  sense  to  develop  a  mission  planning  system  on  a 
machine  which  had  the  processing  and  graphics  power  to  support  mission  planning.  PC 
systems  were  not  advanced  enough  to  handle  the  requirements  levied  on  the  MPS.  The 
PC  software  that  did  exist  was  DOS  based  and  textually  driven.  The  situation  has 
changed  dramatically  since  that  time,  however. 

The  distinction  between  the  Unix  based  workstation  and  modem  Pentium  based  PCs 
boils  down  to  one  thing:  price. ^  Today’s  PC’s  far  outperform  the  current  MPS 
architecture  (at  a  far  smaller  price  tag) — and  are  projected  to  continue  to  get  more 
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powerful  at  a  rapid  pace.  During  a  March  1998  trade  fair  in  Germany,  Intel  demonstrated 
their  new  700  Megahertz  Pentium  II  PC.^°  Scheduled  for  consumer  release  in  1999,  these 
new  processors  will  have  the  same  performance  as  the  world’s  fastest  supercomputer 
only  a  few  years  ago.  The  new  Intel  Merced  processor,  also  due  out  in  1999,  will  run 
even  faster  than  the  Pentium  II.  This  explosion  in  inexpensive  microprocessor 
technology  shows  that  the  initial  justification  for  developing  automated  mission  planning 
on  the  Unix  based  SunSPARC  platform  has  long  since  been  eclipsed.  Future  efforts 
should  be  aimed  at  the  PC  platform,  where  market  forces  will  continue  to  produce  more 
“bang  for  the  buck.” 

Dangers  of  “Joint-Think”  and  Feature  Creep 

The  second  factor  that  has  led  to  the  inadequate  state  of  Unix  systems  today  is  a 
combination  of  misguided  joint  emphasis  and  feature  creep.  The  multiple  stovepipe 
systems  of  the  late  1980’ s  and  early  1990’ s  suffered  from  an  almost  total  lack  of 
compatibility.  When  development  began  on  the  MPS  systems  in  1991,  the  concept  was 
good — to  eliminate  the  problems  of  the  multiple  stovepipes  that  couldn’t  talk  to  each 
other  and  create  systems  which  would  enable  joint  planning.  The  problem,  which  still 
plagues  mission  planning,  is  that  few  understood  what  “joint  planning”  really  meant. 

The  joint  movement  was  just  gaining  momentum  during  this  time  period,  and  words 
such  as  joint,  unification,  integration,  and  interoperability  were  used  without  truly 
understanding  their  impact.  What  was  not  fully  understood  was  that  the  problem  of  the 
multiple  stovepipe  systems  was  not  that  they  were  separate,  but  that  they  couldn’t 
communicate  with  each  other.  What  should  have  been  an  effort  to  enforce 
interoperability  and  integration  of  systems  became  a  quest  for  unification  of  systems  in 
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the  name  of  “joint  mission  planning.”  According  to  Joint  Publication  1-02, 
interoperability  is: 

The  ability  of  systems,  units  or  forces  to  provide  services  to  and  accept 
services  from  other  systems,  units,  or  forces  and  to  use  the  services  so 
exchanged  to  enable  them  to  operate  effectively  together.  2.  The  condition 
achieved  among  communications-electronics  systems  or  items  of 
communications-electronics  equipment  when  information  or  services  can 
be  exchanged  directly  and  satisfactorily  between  them  and/or  their  users. 

The  degree  of  interoperability  should  be  defined  when  referring  to  specific 
cases. 

The  emphasis  is  on  exchange  of  data  and  the  ability  to  work  with  each  other.  This 
does  not  mean  all  systems  must  be  operated  with  common  software  or  interface. 
Unfortunately,  early  efforts  were  directed  towards  eliminating  stovepipe  systems  and 
combining  them  in  one  system.  This  problem  continues  to  threaten  development  of 
future  systems. 

The  impact  of  this  artificial  emphasis  on  “jointness”  is  dilution  of  the  capabilities  of 
a  mission  planning  system  under  development.  The  focus  shifts  from  meeting  the  needs 
of  the  users  of  the  system  to  meeting  the  myriad  requirements  levied  in  the  name  of  joint 
mission  planning.  Many  times  these  joint  requirements  take  developers  deep  into  the 
region  of  diminishing  returns.  An  example  is  recent  guidance  to  incorporate 
collaborative  planning  into  systems  to  support  joint  operations.  This  type  of  requirement 
is  not  necessary  for  the  user  to  plan  his  basic  mission,  but  the  additional  time  and  money 
needed  to  incorporate  this  technology  may  keep  the  system  from  providing  the  basic 
functions  in  a  timely  manner.  The  risk  of  delaying  system  delivery  and  not  meeting 
current  needs  far  outweighs  the  benefits  of  the  desired  future  enhancement.  The  end 
result  is  that  instead  of  trying  to  develop  systems  that  are  interoperable  and  tailored  to  the 
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user’s  need,  systems  are  developed  to  be  unified  and  serve  no  one  in  particular.  This 
problem  is  amplified  by  a  phenomenon  known  as  feature  creep. 

Feature  creep  is  essentially  the  difference  between  trying  to  design  the  80%  solution 
versus  the  110%  solution.  The  MPS  systems  of  today  suffer  from  a  common  flaw. 
During  development,  they  failed  to  keep  in  mind  that  there  is  a  significant  difference 
between  the  needs  of  a  tactical  level  mission  planner,  and  a  unit  or  higher  level  tool  for 
coordinated  planning.  The  MPS  was  loaded  down  with  numerous  bells  and  whistles  that 
allow  for  data  exchange  with  a  plethora  of  outside  sources,  graphics  displays  to  show  the 
big  picture  and  other  features  that  aid  in  centralized  planning.  All  well  and  good,  but  in 
the  process  the  machine  became  so  complex  to  operate  that  the  tactical  level  planners 
have  trouble  simply  planning  from  point  A  to  point  B.  Developers,  or  more  accurately 
those  who  controlled  the  requirements,  failed  to  grasp  that  the  tools  for  centralized 
planning  (operational  and  higher)  may  not  be  the  same  tools  needed  for  decentralized 
execution  (tactical  planning.)  This  continued  hunt  for  features  to  include  in  the  system 
often  results  in  the  systems  diverging  from  the  needs  of  the  users  it  is  supposed  to  be 
servicing.  The  result  is  often  an  end  product  that  is  laden  with  features  users  neither  want 
nor  need — a  phenomenon  known  in  the  commercial  industry  as  “bloatware.” 

This  tendency  to  try  and  “put  it  all  in  one  box”  is  one  that  must  be  addressed  in  any 
future  automated  mission  planning  system  development.  Not  only  does  this  problem 
dilute  any  efforts  aimed  at  providing  the  basic  functions  for  the  planner;  it  also 
contributes  to  the  bureaucratic  phenomenon  labeled  here  as  the  “coordination  threshold.” 
This  is  seen  often  in  organizations  that  begin  small  and  rapidly  expand.  While  the 
organization  is  small,  group  decisions  are  easily  made  since  few  people  are  needed  to 
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reach  a  consensus.  As  the  group  grows  it  becomes  more  difficult  to  reach  a  decision  with 
the  ever  expanding  interests  of  the  group.  In  essence  the  group  hits  a  threshold  at  which 
the  coordination  required  to  make  any  decision  becomes  prohibitive.  At  this  point  the 
project  generally  will  continue  along  its  current  path,  regardless  of  whether  it  is  still  the 
logical  one,  simply  because  it  is  near  impossible  to  get  the  group  to  agree  on  a  change. 
Keeping  the  project  broken  into  smaller,  simpler  parts  avoids  the  “coordination 
threshold”  trap.  It  not  only  makes  coordination  and  decision  making  easier,  but  smaller 
tasks  are  technically  easier  to  accomplish  as  well.^^ 

Controlling  the  complexity  of  current  systems  is  not  unique  to  Air  Force  systems. 
During  the  time  that  the  Air  Force  was  developing  the  MPS  systems,  the  Navy  had  a 
parallel  effort  developing  the  Tactical  Automated  Mission  Planning  System  (TAMPS). 
Another  Unix  based  mission  planning  system,  TAMPS  has  experienced  many  of  the 
same  problems  Air  Force  developers  have  run  into  with  the  MPS  systems.  Rear  Admiral 
Cook  touched  on  the  problem  of  TAMPS  complexity  when  he  identified  the  need  to  work 
towards  “even  less  time  required  for  warfighters  sitting  at  a  machine,  planning 
missions.”^"^  The  Navy’s  TAMPS  and  the  Air  Force’s  MPS  are  currently  investigating 
migration  towards  a  common  system  which  may  help  solve  some  of  today’s  complexity 
problems  for  both  systems. 

The  Next  Step 

Future  Air  Force  direction  in  mission  planning  must  keep  in  mind  that  joint  planning 
requires  interoperability  of  systems,  not  unification  of  those  systems.  Just  as  each  service 
has  unique  requirements  for  their  aircraft,  mission  planning  systems  also  have  unique 
requirements  based  on  their  user  base.  Systems  should  be  designed  and  tailored  so  that 


20 


they  can  meet  the  requirements  of  both  users  and  aircraft,  ranging  from  the  basic 
planning  requirements  of  the  T-38  to  the  advanced  planning  and  data  loading  demands  of 
the  B-2.  Additionally,  these  systems  must  start  with  the  basic  features,  and  make  sure 
those  features  are  not  sacrificed  in  a  mad  rush  to  make  it  bigger  and  better. 

Automated  mission  planning  has  moved  from  a  luxury  to  a  necessity  for  many 
aircraft,  not  just  the  F-16.  It  has  reached  the  point  that  the  mission  planning  system  is  as 
critical  a  part  of  the  aircraft  as  the  engine  or  flight  controls.  For  aircraft  such  as  the  F-16 
Block  50,  without  a  mission  planning  system  to  plan  the  mission  and  load  the  DTC  the 
mission  cannot  be  flown  effectively.  There  is  far  too  much  preflight  data  processing  and 
transfer  required  to  even  attempt  to  do  it  without  a  mission  planning  system.  In  light  of 
this,  the  problems  identified  become  particularly  troublesome.  Continuing  to  rely  on  the 
MPS  systems  tie  us  to  the  limitations  and  difficulties  of  size,  cost,  usability,  and 
portability.  This  de  facto  bottleneck  in  mission  planning  capability  can  only  be  addressed 
by  examining  why  we  are  at  this  juncture,  and  what  the  proper  direction  should  be  from 
this  point  to  best  serve  our  mission  planning  needs  of  the  future. 
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An  MPS  I  is  pictured.  The  second  generation  system,  MPS  II,  has  reduced  the 
footprint  to  approximately  50  square  feet  per  two  station  system. 

PFPS  can  be  run  on  any  Windows  compatible  machine.  It  can  be  as  small  as  the 
notebook  shown  here  with  built  in  CD  and  ODD-3  loading  device;  or  it  can  be  a  much 
larger  desktop,  tower,  or  network  server  machine.  It  is  the  user’s  discretion  to  configure 
the  system  to  meet  their  needs. 

^  Joint  Vision  2010,  Joint  Staff  Study,  1996,  5. 

^  Dave  Medeiros,  TYBRIN  Corporation,  interviewed  by  author,  March  1998. 

^  Major  Tom  Martin,  HQ  ACC/SMO-P,  interviewed  by  author,  January  1998. 
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Chapter  4 


The  Future — Breaking  With  Tradition 

On  The  Horizon... 

Automated  mission  planning  is  going  to  be  a  critical  part  of  any  future  aerial 
undertaking.  Hopefully,  future  efforts  can  learn  the  lessons  of  the  recent  past  and  better 
serve  the  needs  of  the  aircrews  who  need  these  systems  to  accomplish  the  mission.  In 
that  vein,  there  are  currently  three  efforts  which  hold  some  promise  for  the  future  of 
automated  mission  planning:  Joint  Mission  Planning  Segment,  CyberWarrior  Insights, 
and  Flight  Information  Enhancement. 

Joint  Mission  Planning  Segment 

The  Joint  Mission  Planning  Segment  (JMPS)  is  a  cooperative  development  effort 
between  the  Navy  and  the  Air  Force  to  migrate  the  Navy  Tactical  Automated  Mission 
Planning  System  (TAMPS)  and  the  Air  Force  Mission  Support  Systems  (AFMSS)  into  a 
common  family  of  mission  planning  systems.^  The  primary  objective  of  JMPS  is  to 
provide  a  scaleable  product  that  allows  users  to  configure  systems  tailored  to  their 
specific  needs.  It  should  concentrate  on  enabling  exchange  of  information  at  the  unit, 

wing,  and  higher  headquarters  levels  for  collaborative  interservice  planning.  Above  all, 

2 

IMPS  designers  want  to  achieve  “an  end-user  perception  of  a  high  performance  system.” 
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This  project  holds  great  promise  to  break  with  the  problems  of  the  past  for  several 
reasons.  First,  the  development  effort  is  focusing  on  the  customer’s  needs.  The  target 
user  of  IMPS  will  be  an  aircrew  member  from  an  operational  unit — the  warfighter  who 
will  use  the  system.  This  in  itself  will  avoid  the  problem  of  feature  creep  that  the  MPS 
systems  exhibited.  Reinforcing  this  positive  approach  is  the  strong  push  from  the 
operational  communities  to  limit  the  scope  of  initial  IMPS  releases  to  unit  level  roles  and 
responsibilities."^  Once  the  system  has  proven  the  ability  to  do  the  basics,  then  and  only 
then  will  higher  command  features  be  added  to  the  system. 

The  problems  of  cost  and  hardware  dependence  are  also  being  addressed.  The  IMPS 
concept  calls  for  platform  independent  software,  so  it  can  be  installed  on  a  Windows  NT 
PC  or  a  Unix  machine.  If  the  concept  survives  as  envisioned,  IMPS  will  be  a  family  of 
mission  planning  systems.  The  systems  can  then  be  configured  as  small  as  a  flight 
planner  on  a  notebook  system,  or  as  large  as  a  full  mission  planning  system  on  a 
networked  workstation.  The  user  decides  the  level  of  complexity,  cost,  and  features  they 
desire.  The  IMPS  concept  does  an  excellent  job  of  providing  a  hardware  independent 
scaleable  solution  to  today’s  problems. 

CyberWarrior  Insights 

CyberWarrior  Insights  is  an  initiative  spearheaded  by  the  Air  National  Guard  and  Air 
Force  Reserves  to  develop  automated  tools  for  squadron  level  scheduling  and  training 
functions.^  These  tools  are  intended  to  be  add-on  modules  for  the  PC  based  PFPS 
software  which  will  provide  a  “virtual  scheduling  and  training  shop”  for  the  squadron. 
These  tools  will  help  alleviate  the  current  operations  tempo  problems  by  automating 
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some  of  the  more  time  consuming  tasks,  either  freeing  members  up  to  perform  other 
duties  or  allowing  them  more  time  home  with  families. 

There  are  four  major  areas  targeted  under  the  CyberWarrior  Insights  project.  First,  it 
is  attempting  to  automate  the  links  between  the  flight  planning  system  (PFPS)  and  the 
squadron  scheduling  system.  This  will  give  planners  access  to  real  time  changes  in  their 
sortie  data  such  as  what  length  sortie  they  are  planning  for,  what  ranges  are  available,  and 
other  data  pertinent  to  planning  operations.  The  automated  links  will  inform  the  planners 
of  changes  without  having  to  constantly  return  to  the  scheduling  shop  to  get  the  latest 
updates. 

The  second  area  under  CyberWarrior  Insights  development  is  a  link  between  the 
schedule  and  currency/training  tracking.  This  will  allow  the  schedulers  automated  access 
to  currency  and  training  requirements  of  the  pilots  so  they  can  more  efficiently  build  a 
schedule  that  meets  squadron  requirements.  It  also  automates  the  process  of  updating  the 
currency  and  training  data;  thus  removing  the  need  for  time  consuming  human  tracking. 
The  third  area  under  development,  similar  to  the  training  and  currency  tracking,  is 
integration  of  “bean  counting”  for  the  weapons  shop.  This  is  another  feature  that  replaces 
time  intensive  human  tracking  with  an  automated  function  that  will  track  weapons  event 
accomplishment. 

The  final  area  being  studied  under  CyberWarrior  Insights  is  methods  to  enhance 
training  opportunities.  The  most  promising  of  these  is  a  PC  system  that  will  produce  not 
only  fly-throughs  of  a  planned  mission,  but  will  also  allow  for  free  roam  simulation  while 
planning.  This  will  allow  pilots  to  better  visualize  “what  if’  scenarios  when  planning  a 
mission,  and  will  better  familiarize  them  with  mission  variables. 


25 


The  combination  of  the  CyberWarrior  Insight  initiatives  will  allow  for  automation  of 
many  of  the  time  consuming  tasks  scheduling  and  training  personnel  currently  perform 
manually.  This  virtual  training  and  scheduling  shop  will  use  tools  that  integrate  with 
PFPS  software  and  provide  warriors  with  the  means  to  more  effectively  use  their  time 
and  better  prepare  for  missions. 

Flight  Information  Enhancement 

Flight  Information  Enhancement  (FIE)  is  similar  to  CyberWarrior  Insights.  Where 
CyberWarrior  Insights  is  working  towards  developing  virtual  scheduling  and  training 
functions,  EIE  is  exploring  the  virtual  base  operations  concept.  It  will  also  be  an  add-on 
package  that  integrates  with  the  PEPS  suite.  PIE  is  currently  exploring  three  functional 
areas,  all  of  which  center  around  linking  Air  Porce  mission  planning  to  data  available  on 
the  World  Wide  Web  (WWW). 

The  first  area  is  integration  of  weather  information.  The  ultimate  goal  of  PIE  is  to 
allow  pilots  to  link  a  PEPS  route  to  WWW  weather  information,  with  data  flowing  both 
directions.  This  will  allow  not  only  review  of  weather  status  along  the  route,  but  will  also 
feed  wind  information  back  into  the  flight  planner  to  produce  a  winded  flight  plan.  The 
initial  operational  capability  (IOC)  of  PIE  is  scheduled  for  the  summer  of  1998,  and  will 
allow  uploading  of  a  PEPS  route  to  the  WWW  to  display  weather  along  the  route.  The 
feedback  of  data  to  allow  for  recomputation  of  a  winded  flight  plan  will  be  incorporated 
into  future  releases. 

The  next  PIE  function  is  automated  Notices  to  Airman  (NOTAM)  retrieval.  The 
1998  IOC  release  will  only  allow  for  retrieval  of  NOTAMs  by  input  identifier.  Puture 
releases  will  utilize  smart  logic  to  examine  the  PEPS  route,  extract  pertinent  identifiers 
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and  areas  of  interest,  and  provide  the  pilot  with  comprehensive  NOTAM  information  for 
the  entire  route  of  flight. 

The  final  area  FIE  seeks  to  automate  is  the  filing  of  flight  plans  (DD-175). 
Eventually,  EIE  will  provide  the  means  to  generate  and  electronically  file  the  DD-175 
through  the  WWW.  The  IOC  release  will  generate  the  DD-175  and  provide  it  to  the  pilot 
in  a  hardcopy  format. 

All  three  of  these  functions  are  traditionally  base  operations  activities  that  are  time 
consuming.  Base  operations  is  normally  not  in  the  squadron  facility,  requiring  additional 
travel  time  to  accomplish  these  tasks.  By  automating  weather,  NOTAM,  and  flight  plan 
filing  EIE  seeks  to  establish  a  virtual  base  operations  capability  which  will  reduce 
mission  planning  time  for  the  aircrews. 

Emerging  Trends 

The  preceding  discussions  highlight  some  emerging  trends  that  hold  promise  for 
future  mission  planning  systems.  Eirst,  the  course  is  away  from  Unix  based  systems  and 
towards  PC  systems.  This  will  help  alleviate  the  earlier  discussed  problems  of  cost,  size, 
usability,  and  portability.  The  second  trend  is  towards  systems  and  software  that  are 
modular.  Instead  of  trying  to  build  all  possible  functions  for  all  users  in  one  large 
package,  the  new  approach  is  towards  a  mix  and  match  philosophy.  Part  task  tools  such 
as  CyberWarrior  Insights  are  being  developed  which  specialize  at  doing  certain  subtasks 
efficiently.  The  emphasis  is  shifting  from  one  of  unification  of  the  various  systems 
towards  the  integration  of  these  systems.  Einally,  new  development  is  attempting  to 
avoid  the  pitfalls  of  current  systems  such  as  AEMSS  by  striving  for  incremental 
development  of  capabilities.  PIE  is  a  good  example  of  this  trend,  with  the  summer  1998 
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IOC  release  targeting  only  a  subset  of  the  eventual  capabilities  of  the  project.  By  doing 
the  basics  correctly  first,  then  adding  the  “bells  and  whistles”  in  later  releases,  FIE  has 
much  better  odds  at  early  success  and  user  acceptance.  These  trends  are  not  universally 
accepted  as  the  correct  path  to  take.  There  are  arguments  against  some  of  the  new 
directions  in  mission  planning  development. 

Counter  Arguments 

Those  who  aren’t  satisfied  with  current  trends  in  mission  planning  development  cite 
four  main  arguments.  The  first  two  are  arguments  against  expansion  of  mission  planning 
on  the  PC  platform:  security  and  performance  capacity.  Both  arguments  are  essentially 
outdated.  The  first  proposes  that  Windows  based  PCs  cannot  offer  the  same  security  as 
Unix  systems.  While  this  was  true  in  the  past,  Windows  NT  4.0  and  beyond  offer 
security  features  just  as  robust  as  Unix  based  systems.^  Similarly,  opponents  argue  that 
only  Unix  systems  can  offer  the  multi-level  security  required  by  some  mission  planning 
functions.  The  PC  architecture  is  physically  capable  of  the  same  multi-level  security 
features,  and  current  developments  in  encryption  are  dating  this  argument  weekly. 

The  second  counter  to  the  PC  mission  platform  is  performance  capacity.  This  was 
discussed  earlier,  and  is  essentially  an  obsolete  argument.  In  fact,  the  development  of 
Intel  Pentium  microprocessors  is  providing  exponential  leaps  in  performance  for  a 
fraction  of  the  cost  of  other  comparative  systems  such  as  the  SunSPARC  stations 

o 

currently  used  for  MPS  systems. 

The  third  argument  against  any  change  in  mission  planning  development  is  the 
substantial  cost  of  rewriting  all  legacy  code.  While  at  first  this  may  seem  to  be  a  valid 
point,  further  consideration  shows  that  it  is  a  hollow  argument.  Not  all  legacy  code  needs 
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to  be  rewritten.  Each  system  should  be  examined  to  see  if  it  meets  the  needs  of  the  users, 
and  how  much  longer  the  system  will  need  to  be  maintained.  There  are  several  options 
when  considering  what  to  do  with  legacy  code.  If  the  code  is  still  doing  the  job  for  the 
user,  then  all  that  may  need  to  be  done  is  write  interface  code  to  integrate  the  old  system 
with  the  newer  systems.  Even  if  the  decision  is  made  to  migrate  the  code  into  the  newer 
systems,  the  tools  for  automatic  code  generation  have  significantly  reduced  the  effort 
required  to  move  to  the  new  system.  If  the  legacy  code  no  longer  meets  the  needs  of  the 
users,  then  the  code  will  need  to  be  updated  in  any  case.  Again,  automated  tools  can  help 
migrate  to  newer  systems. 

The  last  major  argument  against  current  mission  planning  trends  is  the  attitude  that 
“the  new  system  can’t  meet  our  requirements.”  This  argument  is  generally  made  without 
a  full  understanding  of  the  facts.  As  an  example,  the  Navy  was  hesitant  to  even  consider 
PEPS  as  a  tool  to  supplement  their  TAMPS  system.^  They  initially  felt  that  the  PC  based 
PEPS  couldn’t  possibly  handle  the  requirements  for  Naval  mission  planning.  Once  they 
sat  down  and  were  shown  the  capabilities  of  a  PEPS  system,  however,  they  immediately 
incorporated  it  into  their  mission  planning  roadmap  as  a  major  component  carrying  them 
into  the  future. 

Notes 
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Chapter  5 


Conclusion 

Those  who  cannot  remember  the  past  are  condemned  to  repeat  it. 

— George  Santayana 

Automated  mission  planning  is  no  longer  a  luxury.  Without  the  proper  systems  to 
support  mission  planning  at  the  tactical  level,  the  aircraft  are  just  as  ineffective  as  if  the 
engines  are  removed.  Future  development  must  consider  the  path  mission  planning  has 
taken  in  the  past  and  actively  try  to  avoid  the  same  pitfalls.  Both  hardware  and  software 
issues  must  be  addressed. 

Past  justification  for  using  large  Unix  based  systems  is  no  longer  valid.  Unix 
systems  are  no  longer  required  for  the  data  processing  needs  of  the  user,  and  are  difficult 
to  use  in  today’s  PC  prevalent  society.  The  cost  in  dollars,  floor  space,  and  training  can 
no  longer  be  justified. 

Software  development  is  particularly  susceptible  to  the  problems  of  the  past.  The 
rush  to  provide  marginal  capabilities  sometimes  tramples  the  bottom  line  need  for  the 
basics.  Future  systems  should  emphasize  providing  the  basic  mission  planning  features 
first  -  the  80%  solution.  Once  this  has  been  provided,  new  features  can  be  added  in  later 
releases.  Due  to  the  rapid  pace  of  technology  growth  today,  the  hunt  for  the  110% 
solution  may  even  result  in  development  paralysis.  Releases  are  constantly  held  up  for 
“one  more  feature”  and  never  get  completed — as  there  is  always  one  more  carrot  to  delay 
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for  on  the  horizon.  Beyond  the  individual  planner,  the  system  should  concentrate  on 
interoperability  with  other  systems.  This  will  emphasize  the  sharing  of  data  and  files  to 
improve  the  mission  planning  process,  but  does  not  mean  that  all  systems  are  locked  into 
one  master  configuration — nor  that  all  users  inherit  the  overhead  of  unneeded  features 
found  in  other  systems.  Emphasis  on  the  PC  platform  provides  the  opportunity  for 
numerous  commercial  off-the-shelf  (COTS)  solutions  and  significantly  increases 
competition  for  those  contracts.  Dollars  previously  used  in  the  development  of  expensive 
Unix  solutions  can  be  directed  elsewhere. 

The  danger  of  not  heeding  the  lessons  of  the  past  will  be  a  failure  to  meet  current  and 
future  operational  needs.  In  the  near  future  mission  planning  systems  must  be  smaller, 
cheaper,  easier  to  use,  and  PC  based  to  meet  the  needs  of  the  warfighter.  Smaller  systems 
are  needed  to  support  current  operational  employment  concepts  such  as  the  Aerial 
Expeditionary  Eorce  (AEE).  Current  AEE  plans  include  reducing  the  airlift  requirement 
as  much  as  possible  to  enable  quick  reaction.  Current  MPS  systems  require  one  to  two 
pallets  to  airlift  each  into  the  theater  of  operations.  Switching  to  PC  based  systems 
reduces  airlift  requirements  substantially  for  an  AEE  movement.  Cheaper  systems  are 
needed  to  support  the  lean  logistics  concept.  The  MPS  systems  are  larger  and  more 
expensive  to  repair  than  PC  hardware,  which  are  almost  disposable.  A  much  smaller 
logistics  footprint  can  be  maintained  through  utilization  of  PC  systems,  and  any 
necessary  repairs  will  be  both  cheaper  and  easier  to  obtain. 

Mission  planning  systems  must  also  concentrate  on  ease  of  use.  Today’s  battlefield 
is  a  more  mobile  and  lethal  arena  than  ever  before.  The  shift  towards  precision  strike  on 
almost  all  platforms  puts  a  larger  burden  on  the  mission  planning  systems  since  they 
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become  the  pacing  function  in  joint  precision  interdiction  timeliness/  It  is  also  becoming 
increasingly  obvious  that  the  United  States  will  rarely,  if  ever,  fight  a  purely  unilateral 
operation.  This  means  that  our  mission  planning  systems  will  have  to  take  into 
consideration  interoperability  with  not  only  US  systems,  but  those  of  our  multinational 
partners  as  well.  Many  nations  have  already  approached  the  United  States  to  purchase 
mission  planning  technology.  The  preponderance  of  interest  has  weighed  heavily  in 
favor  of  PC  based  planning,  due  to  its  low  cost.  Moving  US  mission  planning  in  this 
direction  will  substantially  increase  our  chances  of  interoperability  with  our  allies. 

Mission  planning  development  will  also  have  to  consider  the  implications  of  the 
future  battlespace.  Joint  Vision  2010  lists  five  areas  of  dynamic  change  as  we  move 
towards  2010:  multinational  operations,  enhanced  jointness,  information  superiority, 
technological  advances,  and  potential  adversaries.^  The  first  four  of  these  directly  impact 
mission  planning  systems.  As  discussed  above,  increased  multinational  operations  will 
require  the  ability  to  integrate  with  allies’  mission  planning  systems — most  likely  PC 
based  systems.  Enhanced  jointness  will  require  the  same  integration  among  our  own 
services,  emphasizing  the  need  for  systems  that  are  not  unified — but  integrated. 
Information  superiority  will  require  the  ability  to  sort,  process,  and  share  data  between 
multiple  systems.  Technological  advances  will  have  to  be  embraced  and  leveraged  to 
further  improve  our  capabilities.  This  means  being  willing  to  let  go  of  past  paradigms 
such  as  Unix  based  mission  planning  and  seizing  the  advantages  of  new  technology  such 
as  recent  growth  in  the  PC  industry. 

If  the  lessons  from  the  past  are  heeded,  the  Air  Force  will  produce  a  system  that  is 
easy  to  use,  cost  effective,  portable,  and  scalable.  It  will  provide  mission  planning 
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capabilities  to  support  today’s  joint  and  multinational  operations  as  well  as  the  battlefield 
envisioned  in  the  future  in  Joint  Vision  2010.  Past  problems  will  teach  us  how  to  better 
provide  the  warfighters  the  tools  they  need  to  accomplish  the  mission,  and  the  mission 
planning  bottleneck  will  at  last  be  broken. 


Notes 


'  Spilman. 

2 

Based  on  the  author’s  experience  from  1993  through  1997  working  development 
and  testing  of  foreign  military  sales  mission  planning  systems. 

^  Joint  Vision  2010,  6. 
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PC 
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Computer-Aided  Mission  Planning  System 

Combat  Flight  Planning  Software 

Commercial  Off-The-Shelf 

Combat  Weapons  Delivery  Software 

Department  of  Defense 
Data  Transfer  Cartridge 
Data  Transfer  Cartridge  Foader-Reader 

Electronic  Systems  Command 

Flight  Information  Enhancement 
Follow-on  Operational  Test  and  Evaluation 
Flight  Planner 

Georgia  Tech  Research  Institute 

Initial  Operational  Capability 
Integrated  Product  Team 

Joint  Mission  Planning  Segment 

Mission  Planning  System 
Mission  Support  System 

Notice  to  Airmen 

Ogden  Data  Device  (version  3) 

Personal  Computer 

Portable  Flight  Planning  Software 

Portable  Mission  Planning  System 
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TAG 

Tactical  Air  Command 

TAMPS 

Tactical  Automated  Mission  Planning  System 

USAF 

United  States  Air  Force 

USN 

United  States  Navy 

WWW 

World  Wide  Web 
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